With the increasing of the number of broadband users accessed by and the number of the types of services borne on Service Nodes (SN) such as devices including a Broadband Remote Access Server (BRAS), a Service Router (SR), a Broadband Network Access Server (BNAS) and a Broadband Network Gateway (BNG) and so on, the broadband users have increasingly higher requirements on high reliability of broadband services and broadband networks, and the importance of user backup demand between the service nodes is also rising continuously.
The current user backup ways are divided into two ways: cold backup and hot backup. The cold backup can implement a fault secure on the SN and uplinks and downlinks thereof, and when a fault occurs, a secure effect is implemented through switching between the SN devices, but the users are required to reacquire a network address, and most of the services including real-time services also need to be retriggered. The hot backup way requires that all state information of the users should be synchronized in real time on two SNs, including a user online state, a service state and a protocol state and so on, the advantage of the hot backup lies in that a fault secure unperceived by the users can be implemented, and when a fault occurs on the SN or the uplinks and downlinks thereof, switching between the SNs can be implemented and user addresses and services can be kept without interruption.
In the hot backup scheme, protocol state backups of the users include state backups for various protocols, such as states of user access protocol (i.e. Point to Point Protocol (PPP)), Dynamic Host Configuration Protocol (DHCP), user authentication authorization and accounting protocol (i.e. Remote Authentication Dial In User Service (Radius)), portal authentication protocol (Portal), and a tunnel of a user-related network side protocol (i.e. Layer 2 Tunneling Protocol (L2TP)) and a session state and so on. When there exist multiple backup groups between an active BNAS device and a standby BNAS device, multiple backup groups of the same service node may share the same Authentication Authorization and Accounting (AAA) server, DHCP server or Portal server and so on. If these backup groups perform message interaction with these servers through uniform local Internet Protocol (IP) addresses, when a state of a certain backup group on a service node turns from an active state into a standby state and states of other backup groups still keep active (for example, a fault occurs in a downlink of the service node corresponding to the backup group), the service node will still receive the protocol messages related to all the users which are sent from the servers to the service node, such as Change of Authorization (COA) message of the Radius and so on, including messages related to the user in a backup group whose state has been switched to standby, but it is required to send this part of protocol messages to a service node on which a state of the backup group is active at this point (this requirement cannot be met in the related art). Therefore, it will cause that the user-related protocol messages in a user service backup protocol cannot be completely synchronized.
If it is wished to correctly send all the user-related protocol messages such as Radius, DHCP and Portal of each backup group to the service node on which the state of the backup group is active, it is required to set a separate local IP address for each backup group so as to communicate with theses servers and to configure different backup groups to go through different local IP addresses on the service node; thus, protocol connection required to be maintained by the server side is aggravated, and meanwhile configuration complexity and configuration error risk of the service nodes are also aggravated.